1. Technical Field
The present invention relates generally to an improved data processing system and method. More specifically, the present invention is directed to a system and method for navigating beans using filters and container managed relationships.
2. Description of Related Art
Enterprise Java Beans (EJBs) are software components in Sun Microsystem's Java 2 Enterprise Edition (J2EE) platform, which are written as software modules that contain the business logic of an application. EJBs reside in, and are executed in, an EJB container, i.e. a runtime environment which provides common interfaces and services to the EJB.
There are three basic types of EJBs: session beans, entity beans, and message driven beans. Session EJBs are used to perform processing. Entity EJBs are used to represent data, which may be a row or a table in a database, for example. Message driven EJBs are generated to process Java Messaging Service (JMS) messages. EJBs may be used to implement tables and databases, for example, using entity EJBs to represent the elements in the tables and/or databases.
In generating applications for addressing business situations, often complex relationships between EJBs are required to accurately reflect real-world conditions. In the original Java specification, however, EJBs made such complex relationships more difficult to implement because developers had little control over when an EJB was activated or made passive. As a result, developers often were required to generate complex logic to ensure object persistence within these relationships.
Recognizing a problem with the original Java specification for EJBs, the EJB specification developers at Sun Microsystems have added container-managed relationships (CMR) in EJB specification 2.0 and 2.1 specification. With the original EJB specification 1.0 and later specification 1.1, container-managed fields were identified by placing attributes in the bean and describing the fields in the deployment descriptor. Although other entity beans could reside within a parent entity bean, the container did not automatically handle their persistence or loading. Therefore, the bean developer was required to write additional code to handle these additional entity beans.
With the EJB 2.0 and 2.1 specification, container-managed fields now have abstract getters and setters to identify them rather than attributes within the bean. The getters' return types depend upon the relationship's type. If a single child-bean instance is returned, the instance return type is the child bean's local interface. In contrast, if multiple child-bean instances return, the return type of the generated method is a java.util.Collection or a java.util.Set, however the contents of these collections are instances of the child-bean's local interface. The bean developer can then describe the relationship, defined within the deployment descriptor's relationship tag, in the EJB's deployment descriptor.
FIG. 1 is an example of a deployment descriptor for an EJB having a relationship tag, taken from “Container-Managed Relations for the 21st Century,” by Allen Fogleson, Apr. 19, 2002 available from JavaWorld (www.javaworld.com). The example shown in FIG. 1 defines a user bean with a one-to-one, unidirectional relationship to a demographics bean.
The relationships tag tells the container that the user describes the relationships of the beans contained in this deployment. Each relationship starts with the ejb-relation tag. The ejb-relation-name tag is a human-readable description of the relationship. The ejb-relationship-role tags, of which there are two in each ejb-relation, describe each entity bean's role in this relationship. Each ejb-relationship-role tag contains a human-readable ejb-relationship-role-name tag and describes that bean's role in the relationship. The multiplicity tag describes whether the bean is on the relationship's one or many side. The relationship-role source contains an ejb-name tag, which is the entity bean that participates in the relationship. The ejb-name tag must match one of the EJBs defined in an EJB Java Archive (JAR) file.
The cmr-field tag is optional. If the described bean lacks a CMR field, it will not be included as demonstrated in the second ejb-relationship-role tag above. However, the cmr-field tag is required for beans that have a CMR field. The text within the tag contains the cmr-field-name tag describing the name of the CMR field to use in the relationship. Finally, the cascade-delete tag, included in the bean that is the relationship's child, tells the container that if the relationship's parent is deleted, the parent's children should also be deleted.
The EJB 2.0 and 2.1 specification's persistence scheme may be used to represent eight relationships: one-to-one unidirectional, one-to-one bidirectional, one-to-many unidirectional, one-to-many bidirectional, many-to-one unidirectional, many-to-one bidirectional, many-to-many unidirectional, and many-to-many bidirectional. In one-to-one unidirectional relationships, the parent bean references one child entity-bean instance. In one-to-one bidirectional relationships both the parent and child beans reference each other.
In one-to-many unidirectional relationships, the parent entity bean references many child entity beans, and the child entity beans mean little without the parent. In one-to-many bidirectional relationships, each bean in the relationship references every other bean. The parent bean has many child beans, and each child bean references its parent.
In many-to-one unidirectional relationships, many parent entity beans reference a single child entity bean. However, the child entity bean does not refer back to the parents. Although many-to-one bidirectional relationships can easily be modeled under the EJB 2.0 and 2.1 specification's persistence scheme, they are not really unique relationships because they are identical to one-to-many bidirectional relationships.
In many-to-many unidirectional relationships, many parent beans reference many child beans. The child beans either mean nothing without the parent, or it is not necessary to look up a parent bean based on a child bean. In many-to-many bidirectional relationships, many parent beans reference many child beans, which likewise reference many parent beans.
The entity EJB models each relationship type using abstract accessors. The return type is either a local interface or a local interface collection. Since relationships use local interfaces that can work only within the same virtual machine, relationships cannot be created with other distributed entity beans. As a result, local interfaces are extremely fast. Because a remote call's overhead no longer exists, local interface calls act just like other local method calls to a regular Java class.
For more information about EJBs and container managed relationships, reference is made to the article “Container-Managed Relations for the 21st Century,” by Allen Fogleson available from JavaWorld (www.javaworld.com), which provides examples and illustrations as to how the various types of relationships outlined above are generated using container managed relationship structures. In addition, information regarding how to generate such EJB container managed relationships using the WebSphere Studio™ development application, available from International Business Machines, Inc., may be obtained from “EJB Development Made Easy Using the UML Visualizer in WebSphere Studio,” Daniel Berg, Oct. 6, 2004 (available from the IBM developerWorks website).
With the Container Managed Relationships available in the Java 2.0 and 2.1 specification, application developers can now design and encode complex relationships among many entity beans without resorting to custom logic in their entity-bean implementation class. Application developers may construct one-to-one, one-to-many, or many-to-many relationships without worrying about the entity bean's state. The container now ensures child beans properly persist, activate, and load.
While Container Managed Relationships (CMRs) provide a great advantage to application development over the prior Java 1.0 and 1.1 specifications, there are limitations to the power that CMRs provide. One limitation of CMRs arises in instances where one-to-many and many-to-many relationships occur. With such relationships, it is often necessary to retrieve a single result, rather than many results that would normally be retrieved using the one-to-many or many-to-many relationships.
As an example, assume that there are two container managed persistence (CMP) EJBs, department and employee, that have a one-to-many relationship, i.e. each department has many employees but each employee has only one department. Under the current CMP mechanism for defining a relationship, a developer can only define a relationship of the form getEmployees on the department EJB which will return all employees within the department. That is, with the current Container Managed Relationship mechanisms, a developer can only define simple relationships in which the main attributes are the entities involved, the multiplicity (cardinality) of each end of the relationship, and the role name of each end of the relationship. As a result, only large grain CMP operations are available through the CMR mechanisms.
To identify a particular employee, or group of employees, within the department, a developer would be required to define additional SELECT methods on the department EJB that contained the required EJB query language to navigate the relationship and restrict the employees returned within a WHERE predicate. Thus, developers are forced to write several SELECT methods to retrieve more specific data for each possible employee or employee group type, e.g., getMaleEmployees, getFemaleEmployees, getEmployeesOver60, etc., on the department EJB. In addition, developers must also write corresponding business methods that invoke the generated SELECT methods and promote the new business method to the local or remote interface so that it is accessible to clients of the EJBs. Therefore, much effort is placed on the developer to provide the necessary methods to provide fine grain navigation of relationships between EJBs.
In addition, problems arise with using Container Managed Relationships to handle insert only databases. That is, one common data warehousing technique is to make database tables insert only thereby reducing contention and improving performance. A side effect of this approach is that each table within the database defines a number of columns that are used in conjunction with the logical keys in order to uniquely identify an individual row. The most important column used in this manner is the insert timestamp column. The insert timestamp columns only have meaning within the table in which they are defined and cannot be used as part of a foreign key in another table, since the insert timestamp for a row in one table may be different to the insert timestamp for a row in another table even when the rows contain data for related entities.
As a result, when using Container Managed Persistence (CMP) of Container Managed Relationships to model these tables, the insert timestamp column cannot be used as a key column for the beans because they would need to include it in any foreign key definitions that might be used to navigate relationships between EJBs. As stated above, these insert timestamp columns have no meaning outside their respective tables and thus, cannot be used as foreign keys and thus, cannot be used to perform Structured Query Language (SQL) join operations, i.e. operations to join entries in two or more tables together.
In addition, if the EJB does not define the insert timestamp column as a key field, the findByPrimaryKey method, used to find entries in a database based on their primary keys, will not return a single instance of the EJB but instead will return multiple instances. This is because entries are not deleted in an insert only data warehousing database. As entries are updated, the updated entry is added as an additional entry without overwriting or deleting the original entry. Therefore, there will be more than one entry that has the same primary key and thus, more than one entry will be returned.
Under the current EJB specification, returning multiple instances using the findByPrimaryKey method is not permitted. As a result, clients of the CMP EJB must be restricted from calling the findByPrimaryKey method. This causes a problem in that many advanced application features rely on methods that make use of the findByPrimaryKey method to perform their functions. For example, in the WebSphere™ integration and application infrastructure software available from International Business Machines, Inc., the Read Ahead Hints and Access Intents features may not be used by the EJB container due to the restriction against calling the findByPrimaryKey method.